Workflow management of software development typically involves coordinating the development of the code with the testing of code. FIG. 1 is an illustrative drawing representing a typical software development and testing cycle 100. The development and testing of complex software code typically is an iterative process. Code 102 ordinarily is subjected to tests while it is still in development. New features are added while software bugs/errors and vulnerabilities are corrected. The development and testing cycle repeats until the code is determined to be sufficiently developed and tested.
More particularly, for example, one or more software architects 104 may contribute to a design of a system architecture that is to be implemented using computer program code. A software development team 106 develops software code features 102 to implement the architecture and also may work in concert with a test engineering team to develop tests 108 for the new code and also to test the existing code for regressions, such as unintended changes to the previously existing behavior, for example. The developers 106 and test engineers 110 ordinarily collaborate in fixing tests, fixing code (e.g., implementing new or additional intended behavior) and in fixing bugs 112 (e.g., deviations from the intended behavior). Development managers 114 manage the overall process and determine when code features are adequately developed, bugs have been sufficiently eliminated and risks are well enough understood to release the code for quality assurance 116.
Dynamic analysis and static analysis are two different techniques used in the automated testing of software code. Dynamic analysis is performed by observing the behavior of code while the code executes on a machine. Static analysis is performed on static code i.e., code that is not running during the analysis process.
Dynamic analysis evaluates runtime behavior of computer code. Instrumentation code is inserted into the code-under-test. The instrumentation code captures runtime information generated in the course of execution of the code for use in observing and evaluating the dynamic, i.e. runtime execution, behavior of the code. U.S. Pat. No. 5,335,344, invented by Hastings, discloses an example of some known software code instrumentation and dynamic analysis techniques. The execution of code during dynamic analysis is driven by tests, which are artifacts that provide input parameters to the system undergoing the analysis. Additionally, tests verify the intended behavior by comparing the output from the system under test with the expected output recorded as part of each test case.
Static analysis can be used to detect kinds of errors that are often missed when using dynamic analysis techniques alone. For example, static analysis may detect an illegal operation that is contained in a rarely traversed or otherwise hard-to-test conditional branch code path that is rarely visited during operation of the software, and that therefore, easily could go undetected during dynamic analysis. Static analysis ordinarily involves use of a variety of different static analysis programs/software tools often referred to as ‘checkers’ to evaluate code paths to identify different kinds of vulnerabilities and/or errors. For example, checkers can be used to detect syntax errors, functions without return values, variables that have been declared but not used, inadvisable automatic type conversions, tainted data, integer overflows, global-variable inconsistencies, problems associated with using modules (e.g., missing or invalid modules or input/export mismatches), to name just a few.
Dynamic analysis and static analysis techniques have been developed that utilize information generated during a build process to identify the code that is to be subjected to analysis. Modern software typically is developed using a modular approach. Teams of programmers may work on different modules or portions of the software. Consequently, source code, compilers, and ancillary software components often are distributed across many different directories and systems. As a result of this complexity, software developers typically use build management utilities such as the “make” program to assist in the process of building executable code.
Dynamic analysis and static analysis can take advantage of the build process by intercepting information about the code generated during a build process and using the information to identify the code to be analyzed. During a typical software development process, source code is compiled to produce an executable script in a high-level programming language, byte code that needs to be further interpreted by an interpreted program, and/or executable binary code that runs directly on the CPU. Different portions of the software may be written using different programming languages that require the use of different compilers, for example. Moreover, different compilers may be used to compile different portions of the source code, even when all of the code is written in the same language. For example, different compilers may produce executable code that runs on computer systems with different microprocessors. A ‘build’ process, which involves identifying the source code files associated with a program and establishing appropriate directory locations, compiler names, and other compilation settings involves many steps, and software developers typically automate such a build process using what typically is referred to as a build program. Both dynamic analysis and static analysis processes may leverage information about source code that is made available during the build process by intercepting information that identifies the code to be statically analyzed. Commonly owned U.S. Pat. No. 7,340,726 invented by Chelf et al. describes examples of some known static analysis techniques that leverage information about code made available during a build process.
Workflow management of the development and testing of software systems that may involve millions of lines of code developed at different times by different individuals is a complex challenge. Keeping code development on schedule while ensuring that the code is adequately tested requires maintaining an up to date record of what code requires testing as the code changes while it is in development. Workflow management often is especially difficult because the code development cycle is interleaved with dynamic and static testing. Keeping track throughout the development and testing cycle of what has been accomplished, what needs to be done and who needs to do what and when is an important but difficult responsibility.